-
Notifications
You must be signed in to change notification settings - Fork 859
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: return 400(StatusBadRequest) http code when the validation failed #3974
Conversation
Signed-off-by: jwcesign <jwcesign@gmail.com>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks~
/lgtm
Hi @jwcesign Could you double confirm it.
Note that I guess that's the reason why controller-runtime take |
While reviewing the K8s code, I noticed that when there are invalid fields, it triggers the The |
Based on the information provided in this link (#3974 (comment)), it is recommended to close this PR. |
Yes, I think so. We are lack of evidence to accept this change. Thanks @jwcesign all the same~ |
What type of PR is this?
/kind bug
What this PR does / why we need it:
Currently, the webhook returns a 403 (forbidden) status code when validation fails. However, this is incorrect as it should only occur when there is insufficient privilege.
I have tested this with K8s and found that if the field is not correct, the expected status codes are either 400(StatusBadRequest) or 422(StatusUnprocessableEntity). Therefore, we should adhere to this rule.
There is no clear distinction between 400 and 422. In both cases, a parameter error occurs. Therefore, I have modified the relevant code to always return a response of 400.
Which issue(s) this PR fixes:
Fixes #none
Special notes for your reviewer:
Does this PR introduce a user-facing change?: